Add weekly TestFlight public-beta promotion#25712
Conversation
Generated by 🚫 Danger |
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 32926 | |
| Version | PR #25712 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 94013dd | |
| Installation URL | 3h467tcq0skg0 |
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 32926 | |
| Version | PR #25712 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 94013dd | |
| Installation URL | 15u36o3dd3aeo |
0f7c509 to
f7b8306
Compare
Promote the last processed build of the day to the Nightly Beta Testers group for WordPress and Jetpack — a metadata-only App Store Connect call, no rebuild. Runs automatically on a daily schedule (`promote_nightly_build` lane + .buildkite/promote-nightly.yml). Distributes for real only on trunk (the scheduled branch); anywhere else it's a dry run.
f7b8306 to
a5ed744
Compare
List the nightly-group builds in Slack and let a developer pick one from a Buildkite block step, then promote it to public beta (gather_testflight_candidates + promote_build lanes + .buildkite/promote-testflight.yml). Candidates are scoped to the latest marketing line and the last 7 days, newest first, and the Slack message links straight to the block step's unblock dialog.
a5ed744 to
94013dd
Compare
oguzkocer
left a comment
There was a problem hiding this comment.
This looks good to me ![]()
I did wonder a little bit about these cases, but they seem to be covered:
- What happens to the nightly build if there are no new builds in
trunk(succeeds silently by not promoting anything) - What happens if a previously promoted build becomes a candidate for the next day (seems unlikely and safe with the current values)
- Can we ever accidentally promote an older build than that's already promoted, especially in nightly? (since the builds are ordered by newest, doesn't seem to be possible)
Similar to most everything in fastlane, there are parts that feel slightly flimsy - as in the might break if we change this value and that at the same time stuff - but that's just the nature of these lanes and as far as I can tell, nothing truly worrisome could ever happen. So, I think we ship this and iteratively improve it if and when we find any edge cases.
| # under `set -e` aborts before fastlane runs and bypasses that rescue. A build-level failure | ||
| # notification ensures a broken unattended nightly run still reaches the channel. | ||
| notify: | ||
| - slack: "#build-and-ship" |
There was a problem hiding this comment.
I've been thinking about this on the Android end and I wonder if we should use one of our team's channels for it.
#build-and-ship is very noisy, so it'd be more likely for these failures to go unnoticed. Also, any issues would be addressed by our team and not infra folks - well, most of the time anyway - so, I was thinking either to use a team specific channel, or keep using #build-and-ship, but in the failure message ping our team. The second option would allow keeping that channel muted and still get a heads up. What do you think?
There was a problem hiding this comment.
I figure we can adjust this later as it's an operational concern – right now we put most of the release chatter in #build-and-ship so I figured we'd mirror that to start and can figure out something else later if needed 🤷


Summary
Adds the two beta-promotion tiers on top of the per-commit internal TestFlight builds (#25674), turning "release" into picking a build. Every promotion is a metadata-only App Store Connect call (
distribute_only) — no rebuild.promote_nightly_builddistributes the last processed build of the day to the Nightly Beta Testers group (WordPress + Jetpack).gather_testflight_candidateslists the nightly builds in Slack and opens a Buildkite block step;promote_buildships the chosen build to public beta.How it works
Safety
All three lanes run only on
trunk(the scheduled branch) — on any other branch, or locally, they fail immediately and touch nothing. An off-trunk promotion is a mistake; the guard is a backstop, since the schedules only run ontrunkanyway.Not in this PR
trunk. Setup is documented indocs/testflight-promotion.md.Testing
Validated end-to-end on CI via temporary branch-gated steps (since removed):
trunk